버전 관리 정책을 만들 때 고려해야 할 원칙#
- trunk의 소스코드는 테스트를 통과하며 언제든 deploy 가능한 상태를 유지하는 것이 좋다.
- 커밋되지 않은 코드, 커밋되었으나 trunk에 병합되지 않은 코드, trunk에 있으나 deploy되지 않은 코드는 모두 재고(work in progress)로, 줄일 수록 좋다.
- deploy는 언제든, 누구든 쉽게 할 수 있는 일이어야 한다.
- 어떠한 사전 검사 절차도 production을 대신하지 못한다. 진짜 QA는 production에서 시작된다.
용어 정리#
간결한 서술을 위해 몇 가지 용어를 축약해서 사용한다.
버전 관리
Version Control, Software Configuration Management 등.trunk
HEAD, trunk, master를 통칭deploy
서버에 코드를 배치하고 동작시키는 것. 혹은 배포판을 빌드해서 배포하는 것(distribute).
코드 수정 방법#
일반적인 수정 사항#
새로운 기능을 추가하거나, 버그를 수정하는 등의 일반적인 수정 사항이고, production에 바로 deploy해도 별 문제가 없는 것으로 추정되는 변경사항의 경우.
- trunk에서 최신 소스코드 가져오기 (svn update, git pull, ...)
- 코드 수정, 리팩터링, 테스트
- trunk에 커밋 (svn commit, git add & git commit & git push)
모험적인 수정 사항#
수정된 코드가 제대로 동작하지 않을 가능성이 있거나, 다른 기능을 망가뜨릴 가능성이 있는 것으로 추정되는 경우. 그 외에 여러 가지 개발자가 코드가 안전한지 확신할 수 없는 경우.
- trunk에서 최신 소스코드 가져오기
- 브랜치 만들기
- 브랜치에서 커밋. 중앙 저장소에 통합(git push)할지는 그 때 그 때 판단.
- 작업하면서 주기적으로 trunk에서 최신 변경사항 통합(git pull)
- 테스트 서버에서의 deploy 등으로 개발자가 확신을 가질 수 있는 상태까지 코드 안정화
- 코드가 안정화되면 trunk에 병합(mere)
Deploy (or Distribute)#
- 빌드 머신에서 trunk의 최신 소스 가져오기
- 빌드 & 자동 테스트
- 필요한 수동 테스트
- Deploy
참고자료#
- http://www.jamesshore.com/Agile-Book/version_control.html
- http://www.noop.nl/2008/05/the-single-best.html
- http://www.accurev.com/whitepaper/pdf/SCMBranchingModels1.pdf
- http://blogs.starcio.com/2007/09/top-10-tips-on-version-control-for.html
- http://c2.com/cgi/wiki?CostOfBranching